What about just spilling to stdout or stderr when logdir is not present?

@krono when the gem server is launched from another process (like tODE), stdout is lost and it isn't possible to debug server/script problems, so some sort of default location is needed ... the primary use case for gem servers is the GsDevKitHome environment, but I've got some internal tests that aren't run in GsDevKitHome and I was having a devil of a time figuring out why the tests were failing without log files...

thanks, sounds reasonable

It might be useful to have an option to bypass the log file and spill to stdout (personally I tail the log file when I want to monitor the log). Submit an issue if you'd like to have that as a feature..

It'll be part of the daemontools related stuff anyway

hopefully as an option to spill to standard out ... the gem log files still need to be located on disk in a well-known location

In what sense?
Under daemontools with multilog, the stdout/stderr would end up in a (for this tools) well-known location, but definitely not all in the same directory, but rather an gem-instance specific one

That's not the way I run ss3 (with daemontools) and I'm not sure that I personally like having log files located all "over the place". I'm used to hitting the log dir and looking at the latest files there without having to "wander around":)

Also for GsDevKit, when I am trying to help users, I want to be able to say that they can find the log file in #GEMSTONE_LOGDIR and not have to qualify my statements with "if you are using blah, look here and if you using beh, look there".

With that aid, I have no problem with allowing people to put logs anywhere they please. The defaults are only there to get folks to the point where they can have an informed opinion and decide where things should go ...

No problem, nor any request intended ;)
Any more info in the upcoming issue(s) :)